home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / comm / sansint2.zip / SANSINT2.DOC < prev    next >
Text File  |  1990-11-21  |  4KB  |  71 lines

  1. To: Whom it may concern
  2. From: Lauren A. Colby, 10 E. 4th St., Frederick, MD. 21701
  3. November 26, 1990
  4. Re: Avoiding interrupt conflicts between serial ports
  5.  
  6.      In an earlier memo, I presented a simple basic terminal
  7. program to shut off the interrupts in a serial port and use
  8. polling instead of interrupts, to operate the port. There was an
  9. error in the comments in that program (SANSINT). The terms "LSB"
  10. and "MSB" were reversed. The program still works; the comments
  11. were simply incorrect.
  12.  
  13.      I have worked on the program and made some improvements.
  14. With the new version (SANSINT2), the program looks for a
  15. configuration file (SANS.PRO). If it doesn't find the file, it
  16. asks you for the port address, baud rate, etc., and lets you
  17. configure the port, any way you want. At my home, I have a
  18. machine with add-on ports which use the IBM PS/2 standard. In
  19. that standard (if you can call it a "standard"), COM3 is decimal
  20. 12832; COM4 is decimal 12840. I'm controlling a PAKRATT ham radio
  21. interface on COM4, at 2400 BAUDS, and everything works just fine,
  22. even though I have a mouse on COM1 and a modem on COM2!
  23.  
  24.      I'm giving you the files SANSINT2.BAS, and SANSINT2.EXE.
  25. When you run SANSINT2.EXE for the first time, it will create
  26. SANS.PRO. Be careful to answer the questions correctly; there is
  27. no error trapping. Also, SANSINT2.BAS is written in Quick Basic,
  28. so you'll need Quick Basic if you want to make modifications.
  29.  
  30.      While on the subject of interrupt conflicts, I ran into a
  31. curious problem at my law office, which is worth mentioning. We
  32. have two virtually identical 286 machines, used by the
  33. secretaries. I installed Seiko smart label printers on both
  34. machines. Both printers were installed on COM1. 
  35.  
  36.      One of the machines worked perfectly from the start. With
  37. the other machine, however, the machine would "lock up",
  38. intermittently, when labels were printed. The machine that locked
  39. up had a modem installed on COM2. The machine that worked OK had
  40. no modem.
  41.  
  42.      I called Seiko tech support and was told that the only
  43. solution was to remove the modem; according to the technician,
  44. "ports have a tendency to 'spread out' and create conflicts". I
  45. didn't believe that! I had a hunch that the problem had something
  46. to do with the fact that COM1 uses IRQ4, which has a lower
  47. priority that IRQ3, which is normally used by COM2, and that if I
  48. could just reconfigure the devices to put the printer on COM2 and
  49. modem on COM1, everything would work OK.
  50.  
  51.      In the course of doing the reconfiguring, I discovered that
  52. the serial card which was installed would not work properly on
  53. COM2 and I had to replace the card. With the new card installed
  54. and the printer moved to COM2 and the modem reset to COM1,
  55. everything has worked just fine. It's been six months since the
  56. job was done, and there have been no more lockups. I can't tell
  57. you whether the fix was the new card or the swap in port
  58. assignments. However, because Seiko tech support has apparently
  59. received many complaints about this problem, and there can't
  60. possibly be that many bad cards, I'd guess that simply swapping
  61. ports will work, in most cases.
  62.  
  63.      Incidentally, I don't mean to be critical of Seiko. Their
  64. smart label printers are the greatest product since sliced bread.
  65. If, however, they'd re-write their software to bypass the
  66. interrupts, it would greatly simplify installations. The same is
  67. true for the writers of mouse software and communications
  68. software. At one time, when machines were slow and memory very
  69. limited, the interrupts were useful to cut down on system
  70. overhead. They really aren't needed any more except, possibly for
  71. high speed applications.